Windows Sticky Keys Exploit: The War Veteran That Never Dies

Did you ever hear of Sticky Keys Exploit? You probably did, since it has been known for ages. It was used as an exploit many times, fought in many windows versions, and it has never been killed. That’s why I’m calling it the “War Veteran”, although it never retired…

In short, it’s a Windows privilege escalation exploit that allows you to get a command prompt window with administrative privileges. From there you could, change the user password and log in, for example. But I will explain to you in more detail ahead.

The exploit

Sticky Keys is an operating system GUI accessibility. It was designed to help people with specific disabilities. Putting it simply, it allows modifier keys (Ctrl, Shift, etc.) to remain pressed for some time. 

Let me quickly tell you its story. 

Sticky keys was born in the Mac OS System 6 in the '80s. Windows implemented its version some years later in Windows 95, far from knowing it would be exploited in the future. It happened for the first time on Windows XP and more than 15 years later, it’s threatening to side with other Windows iconic exploits.

But how does the exploit work?

Well, there are some variations to this, but the most common begins with a Windows Startup Repair, be it from the host OS or an installation device. From there you would get a Cmd window, and if all goes well, you should have enough privileges to make changes inside the System32 folder.

All you have to do then is to replace the Cmd (cmd.exe) executable with the Sticky Keys (

sethc.exe

Sounds good? It probably does, but it's so old that it makes you wonder:

Does it really still work? Were there any efforts to fix the "vulnerability"?

Well, first mistake. Sticky Keys is not a vulnerability.

One definition of vulnerability, given by NIST:

“Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.”

In this case, it's not a system vulnerability that is being exploited, but the exploit itself. It can be exploited through the user’s lack of security measures, so it ends being a user responsibility. And it's more like an OS native characteristic.

Now you could ask: but the exploit still works without the need for user improper configuration, right?

Certainly! But perhaps it falls short of importance for the fact it requires physical access to use it. 

So, back to the question, I think that to some extent, there’s a chance that Windows doesn’t want to fully fix this problem.

First, the fact that it's not a vulnerability breaks the need for fixes.

But there's also a chance that this was left on purpose as a way to break into the machine when needed. After all, there are some other tools capable of achieving the exact same thing.

The truth is, I've been following this vulnerability for some time, and if you did it too, you would tell that little or no changes were made for long periods. 

I found and keep finding a lot of material on this vulnerability, from blog posts to YouTube tutorials teaching how to use the exploit. I also found that people keep asking for ways to protect against this, and they even use Microsoft forums. 

Moreover, you can also find some old tutorials telling how this vulnerability has been “documented all over” or old posts where people even then were asking for a solution.

But after all, it appears Microsoft has taken a few measures to protect users against this exploit. I gathered some (there may be others):

• Windows firewall preventing sethc.exe to run Cmd.
• SFC restoring sethc.exe file back to it’s original.
• Forbidding file modifications on the “System32” folder.
• Removing "sethc" from the “System32” folder when accessing through the recovery mode.
• Password protecting Cmd access in the troubleshooting mode.

Given these measures and because I didn't find any recent post, I wanted to be sure that this vulnerability was still exploitable on the latest Windows 10 version.

Let me show you how it went because everyone likes demonstrations. And before you tell me you saw this a hundred times, I tell you that this one had unexpected turns...

Demonstration

I’m not going to go through every step since there’s already a lot of demonstrations and tutorials on this exploit. And my purpose right now is only showing you the present limitations I encountered and the workarounds I found to exploit it.

I started by trying to exploit directly through the native OS troubleshooting mode, and I immediately crashed on the first wall, the password-protected Cmd. I retried the same using a Windows installation image but again hitting the same problem:

After thinking for some time on a solution, I found that this could be a recent limitation since my installation image was the most recent. So I retried the process using an older Windows version and Voilà:

I had a Cmd…

A few commands later and I also had replaced sticky keys…

All I had to now was restart Windows, hit shift key 5 times, and my Cmd window opened. 

Here some people said to have found limitations because the firewall would detect the exploit. This could probably be bypassed by using the first command-line window to disable the firewall, but I had no problem with this.

The real problem appeared then.

It wasn’t supposed to request me any other permissions to change the user password since I was doing it with admin privileges, but still, Windows was refusing it. I guess this is a result of some configuration that I made earlier that deny access to the admin.

I tried some things to get around this problem, but I couldn't find a solution until I remembered...

What about the admin account?

So I checked for the admin account, activated it and was able to change its password.

net user Administrator
net user Administrator /Active: Yes
net user Administrator *

In the end, I didn’t get access to access to the user I wanted (guinea-pig), but I got to access the Admin account - even better. From there I verified that I still had the permission to do pretty much everything, including accessing any personal file from the user account. 

Just for fun, and to show you there’s some other stuff you can do after you get access to an admin account. From a terminal, I executed the following command:

REG ADD HKLM\software\microsoft\windows\currentversion\run /v nc /d “C:\windows\system32\nc.exe -ldp 443 -e cmd.exe

This created a persistent Cmd Shell giving me remote access to the user account through port 443, as soon as the computer booted again. Of course this only works because netcat was installed on the victim’s computer, if not, it's nothing I couldn't do using other attack vectors. For instance, having my hands dirty already, I could simply have netcat executable in a flash drive, and copy it to the victim's computer.

Protecting yourself

Guinea-pig user wasn’t the best example of protection and it’s not your fault that this is exploitable, but now that you know this, any breach you happen to have using this exploit — even though very unlikely — will be all on you.

There are some ways I found to protect your Windows machine:

• Disabling sticky keys keyboard activation (you can still activate it through a button on the login screen).
• Disabling startup repair (sounds awful and insecure)
• BIOS password (good option).

Some of these solutions will work, some better than others and with different setup difficulties. But wouldn't you prefer a simpler and more secure way?

Device Encryption.

That's your answer. It's the first and easiest step you can take to protect against this. This way an attacker would first have to know your password to decrypt the device before being able to use any exploit.

There are different ways you can achieve this encryption in Windows machines. In case you don’t know any, I suggest BitLocker.

If BitLocker happens to be disabled in your country or somehow is not available in your machine, just look for encryption alternatives. As a last resort, go for some of the methods that were previously listed. But be aware that there are variations of this that can be used to exploit other accessibility shortcuts. 

If it's still a no, you can go for the BIOS password. It’s a good solution too.

But know there's more to device encryption. The benefits go way beyond the simple protection against this physical access flaw.

Device encryption will make your computer inaccessible without the password, which means that even with physical access to your computer or hard drive it’s very hard to access your data.

What's your opinion on this? Are you doing something to protect yourself?